As the use of digital technology becomes more pervasive, content such as television programming, music, and movies are being increasingly delivered to consumers in digital format. Content owners, such as record labels, studios, distribution networks, and artists, desire for their content to only be used by certain users or in certain ways. Protecting the copyrights of these content owners from indiscriminate reproduction and distribution poses a considerable challenge in the digital age, as exact duplicates of the content may often be easily created and transmitted to other users.
Content protection schemes for digital media attempt to protect the content enough to discourage at least casual violations of the content copyright while minimizing the cost and processing power necessary to implement the scheme and making the process as transparent to users as possible. One common type of content protection scheme is to encrypt the content with a key. A recipient of the encrypted content with a copy of the key may decrypt and access the content, while a recipient without a copy of the key (such as a third party attempting to improperly access the content) will be unable to decrypt and access the content. The content owner may also revoke a key if it believes the key has been jeopardized, reducing the ability for users to distribute keys to others (such as by posting the keys on the Internet).
Broadcast encryption schemes allow digital delivery of encrypted content without requiring two-way communication between the recipient and source, eliminating the two-way communications (such as handshakes) necessary for many public distribution systems while potentially improving security. By eliminating two-way communications, the potentially expensive return channel on a receiver may be eliminated, lowering overhead and costs for device manufacturers and users. A home network, for example, that shares content among a cluster of different recording or playback devices, such as stereos, personal computers, and televisions, may use a broadcast encryption scheme to protect content in different forms of storage from unauthorized use. Some broadcast encryption schemes, such as International Business Machine Corp.'s (IBM's) eXtensible Cluster Protocol (xCP), provide for binding protected content to a dynamic cluster of networked recording and playback devices, allowing for the content to be managed under a single protection scheme independent of particular storage or transmission interfaces and protocols. Content in IBM's xCP scheme may move freely among devices in the domain but will be useless to devices outside the domain. Other examples of broadcast encryption applications include Content Protection for Recordable Media (CPRM) media, Content Protection for Pre-Recorded Media (CPPM) media, and Advanced Access Content System (AACS) next-generation media.
Broadcast encryption schemes bind a piece of content to a particular entity, such as a piece of media, a server, or a user. Broadcast encryption binds the content by using a media key block (also known as a key management block KMB or session key block) that allows compliant devices to calculate a cryptographic key (the media or management key, or Km) using their internal device keys while preventing circumvention (non-compliant) devices from doing the same. Broadcast encryption does not require authentication of a device and can be implemented with symmetric encryption, allowing it to be much more efficient than public key cryptography. After calculating a media key Km by processing the media key block (MKB), the scheme uses the media key Km to bind the content to an entity (with a binding identifier IDb), resulting in the binding key (Kb). A title key (Kt) is then chosen and encrypted with the binding key Kb, resulting in an encrypted title key (EKt). The content itself may then be encrypted with the title key Kt and the encrypted content may be stored with the encrypted title key EKt. A compliant device that receives the encrypted content and the encrypted title key EKt may use the same MKB and the binding identifier IDb to decrypt the content. The compliant device first may reproduce the same binding key Kb using the MKB, the binding identifier IDb and its device keys, and then decrypts the title key Kt from the encrypted title key EKt using the binding key Kb. Once the compliant device has the title key Kt, it may decrypt the content itself. A circumvention device will not have device keys that can be used to process the MKB and thus will not be able to reproduce the binding key Kb or be able to decrypt the content. Also, if the content has been copied to a different entity with a different identifier IDb′ by a non-compliant device, the compliant device with valid device keys will not be able to calculate the correct binding key Kb because the binding identifier IDb′ is different than the original one.
While the above broadcast encryption scheme provides an effective mechanism for providing encrypted broadcast content to a group of devices, it suffers from some disadvantages. For example, the encryption of the content depends upon the MKB and binding identifier IDb used in the process of encrypting the content, either of which may change frequently under certain circumstances. New MKB's which revoke non-compliant devices may be introduced into a system in some cases, changing the system MKB. If devices are added to or leaves a cluster, the binding identifier IDb changes (by changing the authorization table, one of its components). If either the MKB or binding identifier IDb of a particular entity change, any piece of content that is bound to this entity using a binding key Kb dependent upon them must have its title key re-encrypted using the new values so that compliant devices will still be able to access the content. If there are large amounts of content that need to be changed, re-encryption of the title keys Kt for each of them will require significant amounts of processing time. For content files that are shared over a network, there may also be remote synchronization problems. An arbitration mechanism would be required to ensure that only one device performs the re-encryption of the title keys for a particular piece of content.
The problems described above are exacerbated on many network content-sharing systems with large numbers of small content files, such as home-based or consumer networks. Content is typically delivered to consumers in many small files which results in a very large number of files on a home network. For example, each song oil a music album may be a separate file (and thus have a separate encrypted title key) and a user may have hundreds or thousands of songs. Consumer devices, such as stereos or video players, also typically have relatively small amounts of processing power. The combination of the large number of files to be re-encrypted and the lower capability of consumer devices results in a very inefficient and time-consuming procedure that must be performed each time binding information changes. The problems described above may also occur in Advanced Access Content Systems (AACS) and 4C Entity LLC's Content Protection System. Architecture (CPSA) recordable media where several files may be stored and new MKB's may be introduced into the system.
There is, therefore, a need for an effective and efficient system of encrypting content on a broadcast encryption system. There is a particular need for such a system when there are a large number of encrypted content files to be handled.